Looks reasonable. Can you also add tests to complement the tests for the int-based assertArrayEquals? Thanks.

Done.

Thanks!

Thanks! Can you add a note at https://github.com/junit-team/junit/wiki/4.12-release-notes?

Done.

Could we just use the same of "assertEquals(o1, o2)? instead of "assertArrayEquals", to keep consistent and concise. personally, i dislike something like: assertArrayEquals, assertCollectionEquals...for my tests, i only care about if the two objects are equals, not matter they're array, or collection, or something else.

@lihy70, assertEquals(o1, o2) already applies Java's definition of equals to o1 and o2. Unfortunately, this is not terribly useful in the case of arrays, so assertArrayEquals is a different method you can use to get the more useful behavior.

first of all, let's just think about the use case, i write a test to check if my method return the result which is a int[]. for example by code: {

public void test_m1() {
int[] result = m1(); // assume result = {1, 2, 3}
int[] expected = {1, 2, 3}
assertEquals(expected, result); // By the API spec of the method assertEquals: "Asserts that two objects are equal". "true" should be returned because this is what we expected, right?
}

the assertEquals should call o1.eqauls(o2) first, if it's false, then check if o1 and o2 are array and have same class type, if yes, then call Arrays.deepEquals(o1, o2).

why do i ask this question? because sometimes i happen to use assertEquals to compare the result which is an array and get wrong result. then i looked at my test and said to myself: "fuck, can't it be better? you know what i want"

@lihy70 if we changed assertEquals(Object, Object) as you propose we would need to also change assertNotEquals to match. This would likely break someone.

Have you looked at Truth? See http://google.github.io/truth